Creating Records of Application Management Entities

Before you can work with entities in the Applications group, you will need to create records of entities in the Application Configuration group. These definitions will be selected as values, settings, or configurations in entities of the Applications group and so need to be defined first.

The following entities are a part of the Application Configuration group:

An Application Definition Version record is set in an Application Registration record, which can include multiple application records - each associated with a unique program.

A single Application Definition Version record can thus be associated with applications to multiple programs. You can associate the following with an Application Definition Version record:

  • An application type record
  • Multiple application period records
  • An application definition record

When an application type is linked to an application definition version record, in the Application Definition Version Details record:

  • the Application Period Programs grid displays all the programs linked to the application type, and

  • the Application Period Program Versions grid displays the program versions associated with the programs linked to the application type.

When you create an Application Definition Version Details record, while the end date can be identical to the start date, the time of the end date must be greater than the time of the start date.

Additionally, in an application definition version detail record, when you create an application period program record, you will need to specify date and time values for the Cutoff Date field. The value must be in the range of the parent application definition version detail's start and end date, i.e., you cannot type a date that is prior to the start date or later than the end date of the application definition version detail record.

The reverse is also true - if you type the end date of the parent application definition version detail after saving the child application period program record, ensure that the start and end dates in the parent record are before and after the cutoff date in the child record.

Creation of an associated Lifecycle

In the application definition version record, select from Yes (default) or No in the Create Lifecycle field.

On selecting:

  • Yes - The Lifecycle Type field will be displayed in which you can select one of the following values:
    • Undergraduate Admissions
    • Graduate Admissions
    • New Donor
    An equivalent lifecycle record will be created when staff at the institution create an application. For information about the lifecycle entity, see Creating a LIfecycle.
  • No: The Lifecycle Type field is not displayed.

Program Capacity and Program Version Capacity

In the Application Definition Version Details record, staff members can configure a limit on the number of applications that can be accepted for a program using the following fields:

  • Program Capacity field in the Application Period Programs entity

  • Program Version Capacity field in the Application Period Program Versions entity

Users will not be able to submit applications for a Program/Program Version in Anthology Reach and on portal if the number of applications submitted for a Program/Program Version matches the value configured in the Program Capacity/Program Version Capacity field.

Note
Application submission process in Reach and on portal uses the following configurations for the capacity validation:

  • When an application is associated only with a Program (i.e. Program Version is not associated with the application), the Program Capacity configured in the Application Period Program entity will be used.

  • When an application is associated with a Program and a Program Version, and the Program Version Capacity:

    • is within the limit, the Program Version Capacity will be used.

    • is blank, the Program Capacity will be used if it is within the limit.

    • limit has exceeded, the Program Version Capacity will be used even though the Program Capacity is within the limit.

Enrollment Capacity

The Enrollment Capacity field in the Application Period Programs and the Application Period Program Versions entities of an Application Definition Version Details record enables staff members to set a limit on the number of students that can be enrolled for a program or program versions.

Users will not be able to enroll for a Program/Program Version in Anthology Reach and on portal when the number of applications enrolled for a Program/Program Version matches the value configured in the Enrollment Capacity field.

Note: If an application is associated with a Program or a Program version, the Enrollment Capacity of the Program or Program version will be used. However, if both Program and Program Versions are associated with an application the Enrollment Capacity of the Program Version will be used.

This is an umbrella entity in which records of the following entities are associated:

  • Requirement Definitions
  • Recommendation Definitions
  • Decision Definitions
  • Invoice Definitions

Includes Requirement Definition Detail records that define the type of information needed to process the application. The status of the records can be Not Received, Received, Incomplete or Waived. You need to create these records in the Requirement Definition Details grid. These can include requirements such as essays, test scores, attested resumes, and so on.

In a requirement definition detail record:

  • Each of the following values in the Requirement Type field can be set in multiple instances of the record:
    • General
    • Upload
    • Test Score – enables you to select different tests for which scores can be recorded.
      If you select Test Score, the same combination of values in the Test Score Type and Test Source Type fields cannot be set in multiple requirement definition detail records.
  • The value Recommendation in the Requirement Type field can be set only in a single instance of the record.

  • The value in the Display on Portal field indicates whether to display the requirements on the Application Summary page on the Portal. It can have one of the following values:

    • Yes - Indicates the Requirement will be displayed on the Application Summary page on the Portal.

    • No - Indicates the Requirement will be displayed Application Summary page on the Portal.

    The value configured for the Display on Portal field under the Requirement Definition Detail page is carried over to similar field(s) created under the Application Requirements.

    When the value of the Display on Portal field on the Requirement Definition Detail is modified:

    • The Application Requirements created before the modification will have the older value in the Display on Portal.

    • The Application Requirements created after the modification will have the new value in the Display on Portal.

  • When you change the value of the Conditional field to Yes, you need to select a condition in the Query field. By default, only queries based on the application entity can be selected.
  • In the field Requirement Type with values Official Transcript or Unofficial Transcript, the same value cannot be selected in the field Requirement Education Level if it was previously set in a saved record.

  • The value set in the Status On Submit field in the Requirement Definition and Requirement Definition Details records is used to automatically update the status for a requirement on the portal when a requirement is submitted.

    When a portal user submits a requirement document, the Requirement status on the portal is automatically updated as follows:

    • When the Status On Submit field is not configured in the Requirement Definition and the Requirement Definition Details record, the requirement status is updated as Received.

    • If the Status On Submit field is not set for a Requirement Definition record, the value configured for the Status On Submit field in the associated Requirement Definition Details record will be used for automatically updating the requirement status.

    • When the Status On Submit field is set in the Requirement Definition record and also in the associated Requirement Definition Details record, the requirement status on the portal is updated based on the value set in the Requirement Definition Details record.

Includes records with their details defined in recommendation definition detail records. These records determine if the recommendation is of a specific type – Counselor, Teacher, Co-worker, General or Friend.

Additionally, the following workflows can be included:

  • In the Recommendation Invitation Workflow field: Select cmc_RecInviteWorkflow. This workflow enables the automatic dispatch of an email to the recommender with instructions that the recommender must follow to submit a recommendation.
  • In the Recommendation Thank You Workflow field: Select Recommendation_Thankyou. This workflow enables the automatic dispatch of a thank you email to the recommender when the recommendation is received.

Institutions can create their own workflows that can be selected in these fields or the above workflows can be edited or copied and then used.

Values in the Conditional field and logic in the Query field enable the institution to define the maximum count of recommendations required for a recommendation type. This count is displayed on top of the application form to users.

When creating recommendation definition detail (RDD) records, the value in the No of Recommendations field applies to the value in the field Recommendation Type. For example, when 2 recommendations of type Teacher are required, it means the application requires 2 recommendations from the applicant’s teachers.

The Conditional field can have one of the following values:

  • Yes – The Query field will be displayed in which you need to create or select a query based on the application entity.
  • No – The Query field will not be displayed.

For example, the query can include a condition that 3 recommendations are required for Outstation students, and 2 for Local students.

The following table describes combinations of scenarios to determine the final count of recommendations for each Recommendation Type, which are then added to arrive at the total number of recommendations:

Recommendation Definition Detail Records Value in the Recommendation Type Field Value of the Conditional Field Value in the No of Recommendations Field Whether Condition is Fulfilled Final Count of Recommendations
RDD1 Counselor Yes 3 Yes 3
RDD2 No 2  
RDD3 No 1    
In the above scenario, the value 3 of RDD1 is considered because:
  • The count of recommendations in RDD1 exceeds the count in RDD2 and RDD3, and
  • The conditions in RDD1 is fulfilled.
RDD4 Teacher Yes 1 Yes  
RDD5 Yes 2 Yes  
RDD6 No 3   3
In the above scenario, the value 3 of RDD6 is considered because:
  • The count of recommendations is the highest.
  • The count exceeds the count in RDD4 and RDD5 even though conditions in both records are fulfilled.
RDD7 General Yes 2 No  
RDD8 No 1   1
In the above scenario, the value 1 in RDD8 is considered as the condition in RDD7 is not fulfilled and RDD8 is the only other record with the same Recommendation Type.
  Total Count of Recommendations 7

In the application record, the count of required recommendations will be displayed as follows:

Note: For information about working with queries, see Creating a Query.

Includes decision definition records that define whether to admit, reject, or defer the applicant’s admission.

Note:

  • In the Decision Letter Format field, select one of the following values:

    • HTML - To generate HTML format of the decision letter. It is the default value.

    • PDF - To generate PDF format of the decision letter. Use this format when there are multiple pages in a decision letter.

  • In the Default Decision Letter Template field, templates that are associated with the Decision entity are available for selection. Select a template that will be set as the default template.

  • In associated decision definition detail records, you need to:

    • Associate a Decision Status with each Decision Letter Template. This association determines the format of the letter that will be shown to applicants on the portal.

      Example

      Decision StatusDecision Letter Template
      AdmitAdmit.docx
      DeferDefer.docx
      RejectReject.docx

      The following table describes scenarios that can occur:

      ScenarioDescription
      Scenario 1

      In the Decision Definition Detail record, values are set in the Decision Status and Decision Letter Template fields.

      		The set template will be used to display the decision to the applicant on the portal.
      Scenario 2

      In the decision definition detail record, values are not set in the Decision Status and Decision Letter Template fields.

      		The template set in the Default Decision Letter Template field of the parent decision definition record will be used to display the decision to the applicant on the portal.
      Scenario 3

      Values are blank in the following fields:

      • Default Decision Letter Template - in the parent decision definition record
      • Decision Letter Template - in the decision definition detail record.
      		On the portal, the button to view the decision letter (enrollment) will not be displayed to the applicant in the Decision Details area.

      Notes

      • It is not recommended to create multiple decision definition detail records with the same value in the Decision Status field but with different templates set in the Decision Letter Template field.
      • Invoice definition records for a decision definition are set in instances of Decision Definition Detail records defined in the Decision Definition record.
    • Select a value in the Create Decision Automatically field. If you select Yes, create or select a query you want to apply to the Decision Definition Detail. This framework enables the automatic creation of decisions based on logic in the query. For more information, see Creating a Decision Record.

Includes details of how the applicant will pay the institution toward different heads of expenses such as admission, enrollment, and so on. Select appropriate values in the Invoice Type, Payment Gateway, Payment Gateway Configuration and Payment Method fields.

  • In the Payment Gateway Configuration field, select the appropriate record. By default, payment gateway configurations created for the selected payment gateway will be listed:

    If a record is not selected, settings in the payment gateway configuration record that’s created most recently will be considered when the applicant makes a payment on the portal.

    Note: If the payment gateway is changed, the selected payment gateway configuration will be cleared. Select or create a configuration that applies to the changed payment gateway.

  • In the associated price list record, you will need to create price list item records that are mapped to the fee payment structure in your institution.
  • The Is Fee field in a price list item record can have one of the following values:
    • Yes – indicating that the fee is chargeable by the institution
    • No – indicating that the fee is not chargeable

  • In the Payment Required Before Submission field select one of the following values to enable or disable payment before submitting the application on Portal:

    • Yes - Indicates that the applicant cannot submit the application without making the payment.

    • No - Indicates that the applicant can submit the application before making the payment. The applicant can then make the payment later.

When creating an invoice definition, the Base Entity (Application or Decision) determines whether the institution will generate an invoice for applications or decisions, respectively.

It’s also possible to create custom invoices that enable the institution to charge students based on specific business cases. For example, non-domicile students are billed higher application fees compared to local students.

In the Conditional Products tab

  1. In the Product field, select the application fee product item that belongs to the price set in the parent invoice definition.
  2. In the Query field, create or select a query that you want to apply to the selected product.

    If the value of the Base Entity in the Invoice Definition is:

    • Application – only queries based on the Application entity will be listed.
    • Decision – only queries based on the Decision entity will be listed.

    When creating the query, its base entity must be:

    • Application Registration – if an invoice needs to be generated for an application.
    • Decision – if an invoice needs to be generated for a decision.

    For more information about creating a query, see Creating a Query.

    The selected product will be included in the generated invoice only if conditions defined in the query are fulfilled.

Example

The following invoices will be generated for students A and B:

A is a local student and his invoice amount toward application fees is $100/-.

B is an outstation student and his invoice amount toward application fees is $150/-.

When both applications are processed, the following invoice amounts will be generated:

  Student A - Local Student B - Outstation
Application Fees $100/- $150/-
Total $100/- $150/-

The amounts are different as a result of query conditions included in the Application Fees conditional product.

Note: All products (normal or conditional) will be added to invoices only if the value of the field Is Fee is Yes. Additionally, non-conditional products will be added to all invoices.

Assumption

The Contact Type field based on which the query can be created to define the above behavior includes the following properties:

  • Local
  • Outstation

Users can create records such as Undergrad Application, Part-time application, Employed Student application, and so on. This entity determines the type of application the institution processes.
Programs associated with the application type can be included in the programs grid. These programs are available for selection in the Program field of application records.
Click Add Existing Program to add programs to an application type record.

The name of application type records must be unique.

Users can create records such as Fall Admissions (2018) window , Spring Admission 2019 window, and so on. This entity refers to the period in which applicants are submitting applications.

The name of application period records must be unique.

Includes information of percentage or amount discounts that apply to application fees. Discount code records that are associated with an invoice definition are displayed in the Discount Codes grid in the invoice definition record.